itlawwikiaorg-20200214-history
Y2K problem
Definition The term '''Y2K problem' (also referred to as the "Year 2000 problem", the "Year 2000 computer bug" and the "Millennium bug") "refers to the inability of certain computer software to accurately process dates after December 31, 1999."Peerless Wall & Window Coverings, Inc. v. Synchronics, Inc., 85 F.Supp.2d 519, 522 n.1 (W.D. Pa. 2000). Overview "The use of two digits to represent a four-digit year, and the inherent fault of '00' being interpreted as 1900 instead of 2000, was a standard programming practice throughout the computer industry that had the potential to affect millions of information systems around the world."The Journey to Y2K: Final Report of the President's Council on Year 2000 Conversion, at 2. For instance, 1968 or 1974 would be stored and processed as 68 and 74, respectively. The number 19, indicating years in the 1900s, was implied. This worked smoothly until users started to input dates occurring after December 31, 1999. Computers ran into problems when required to calculate a number based on the difference in two dates, such as the interest due on a mortgage loan. Computers continued to assume that the prefix 19 was implied, so dates such as 00 or 01 were treated as 1900 or 1901. Consequently, computers could not correctly calculate the difference between a year in the 1900s and a year in the 2000s. "The mechanics involved in making any one of these systems capable of correctly processing the Year 2000 date were fairly straightforward, but the scope of the work — identifying, fixing, and testing millions of systems and data exchange points in a global economy — was daunting."The Journey to Y2K: Final Report of the President's Council on Year 2000 Conversion, at 2. Reasons for the Y2K problem There are many reasons for this, some historical, some sociological, and some anecdotal. However, the bottom line was that unless the problem was fixed, the Y2K problem would have begun to manifest itself in computer errors, crashes, data corruption, or other problems. There were many reasons why computer system designers and programmers abbreviated the date field, including the prevalent use of punched cards, the expense of storage, and the programming methodologies used in these early systems. Punched cards In the late 1800s, the U.S. government was facing a data processing crisis of sorts. It was taking the U.S. Census Bureau more than a decade to perform and report the results of the census, which is required by law to be taken every ten years. Something had to be done to tame the flood of census data that was overwhelming the manual tabulation methods used. Herman Hollerith was a Census Bureau employee, who developed an electronic tabulating system using punched tapes, and later punched cards.For additional information on Hollerith, ''see Geoffrey Austrain, Herman Hollerith (Columbia Univ. Press 1982). His system represented information as a series of holes on a punched card.The concept of punched cards did not originate with Hollerith, but rather with a French inventor, Jacquard, who invented punched cards to control the selection of strands on a loom in 1804. See generally Punched Cards (Robert S. Casey & James W. Perry eds. 1951). Each column of the card could represent to a single fact, yes or no answer, or number. In 1884, Hollerith filed a patent on the punched tape system, and later the punched card system. Hollerith’s company (The Tabulating Machine Company), through a series of acquisitions and name changes, eventually became IBM. The Hollerith machines used what became the ubiquitous 80-column “IBM Hollerith cards.”To avoid litigation, Univac Corporation developed a 90-column punched card, which had the same limitations as the 80-column card. Later IBM introduced a 120-column card for its System 3 Minicomputer line. Unfortunately, the 80-column cards imposed limitations on the amount of data that could be recorded on each card. Only 80 bytes of data (1 byte equals 1 character of data) were available. If the data could be shortened, then there would be more available space for additional information.If data for a particular record spanned more than one card, the developer/programmer would have to sequentially number the cards so that they could be sorted correctly and organized properly if the cards were accidentally dropped. This meant that even more data was used up for control purposes, as opposed to unique data associated with a particular record. One solution to squeezing more data on each card was to eliminate the first two digits of the century code, so that 1915 would be entered as simply “15.” If there were several dates on one card, two bytes could be saved for each date. As long as the century stayed the 20th Century, there would be no problem. No computer programmer or manager ever thought that such systems would last for so many years, or even get close to the Year 2000. Computer storage In the beginning of computer history (while officially 1948, the relevant time period actually starts in the 1960s), resources were very limited and very expensive. For instance, the cost of computer memory was $1.00 per byte on a Univac mainframe in 1971. That cost, coupled with technology limitations, meant that even the largest computers could only have a limited amount of memory. Despite this fact, programmers still had to create complex programs, instructions, and data structures to meet the intricate business needs of their clients/employers. In fact, programmers learned to develop rather challenging programs in as little as 4,000 bytes. The nature of the early programmers and their challenges and psychology was very different from today’s programmers. These early programmers developed tricks to cleverly fool the system into processing so much logic, with so little resources — yet with acceptable performance. Today’s programmers most often just buy more memory, faster processors, and more disk storage, to avoid performance and space problems. In addition to the cost of memory, the cost of storing information on disk drives, back in the 1970s and early 1980s, was also very expensive, with a megabyte of storage space costing as much as 10,000 times what a megabyte would cost today. The cost of memory and storage encouraged programmers to take shortcuts as well. One of them was to truncate century dates to the same two digits as was done for punched cards. Again, most programmers in the 1970s and 1980s had no idea that the programs they were developing would still be in use a quarter of a century later. Programming methodology Before there were structured programming, CASE tools, fuzzy logic, and automated testing suites, programmers were a very asocial breed. With virtually no tools and little history before them, they took on the challenges of developing complex software in tremendously small amounts of memory, and with very expensive and limited database capability. To get the job done, they had to make the computer do things that the resources were otherwise incapable of doing. They developed short cuts and tricks to enable their programs to survive and operate in the smallest of machines and using all of the available computer resources. Documentation took up precious space and was an anathema to most programmers. These men and women were brilliant, but the code they left was virtually impossible to maintain, being a beehive of complex and non-intuitive logic intended to make the computer perform beyond its intended capabilities. It is this unstructured, clever, unique spaghetti code that was a great part of the difficulty of fixing and testing Year 2000 problems. Legacy systems "Information technology hardware and software have evolved so continuously over the past 25 years that new applications have been incorporated by modifying slightly older versions of programming and records. The result is that very few systems are completely devoid of code or records from the 1970s and 1980s, when the century turnover seemed too distant to worry about. Further, in the rigorous and non-reflective manner in which microprocessors and computers operate, even one line of code that has not been touched in decades can disrupt or shut down a system, or produce error-laden results."The Economics of Y2K and the Impact on the United States, at 1. Embedded chips "Billions of microprocessors produced over the past 30 years include clock chips . . . set at 'absolute time' beginning with a two-digit year-date followed by months, days, hours, seconds and sometimes milliseconds. Most of these chips have been used in watches or other applications that do not carry risks of causing a cascade of problems. Many . . . have been embedded in a wide range of equipment as convenient timing devices for industrial applications. By subtracting one absolute time from another, for instance, a typical device derives elapsed time for the flow rates in a pump, the timing circuit in a traffic light, or the interval between moving trains. If the device is operating when the year date for the end time shifts from '99 to '00, a malfunction may occur as the device reads an extremely long interval of time or time running backwards. However, if the device is not in operation when the clock turns from 99 to 00, both the start time and the end time may register the same century and the device could continuing operating correctly. These vagaries in results mean that diagnostic costs for this problem are often steep and the consequences unknown. For these reasons, many businesses are dealing with embedded chips by replacing the equipment or by adopting an approach of simply fixing devices after they fail."Id. Systems affected The Y2K problem affects two general classes of equipment. The first class comprises business systems or mainframe systems. The second class of equipment has several common names, including embedded chips, embedded processors and embedded control systems. Impact on organizations Y2K-related failures in business systems will generally cause an enterprise to lose partial or complete control of critical processes. In the private sector, loss of business systems means that a company may have difficulty managing its finances, making or receiving payments and tracking inventory, orders, production or deliveries. In the public sector, government organizations may be severely hindered in performing basic functions such as paying retirement and medical benefits, maintaining military readiness, responding to state and local emergencies, controlling air traffic, collecting taxes and customs and coordinating law enforcement efforts. References See also * The Economics of Y2K and the Impact on the United States * Year 2000 compliant * Year 2000 Computing Challenge: Federal Business Continuity and Contingency Plans and Day One Strategies * Year 2000 Computing Challenge: Noteworthy Improvements in Readiness But Vulnerabilities Remain * Year 2000 Computing Crisis: An Assessment Guide * Year 2000 Computing Crisis: A Testing Guide * Year 2000 Computing Crisis: Business Continuity and Contingency Planning * Year 2000 Computing Crisis: Customs Has Established Effective Year 2000 Program Controls * Year 2000 Computing Crisis: Time is Running Out for Federal Agencies to Prepare for the New Millennium * The Year 2000 Problem * Year 2000 Project * Y2K * Y2K Action Weeks * Y2K Computing Challenge: Day One Planning and Operations Guide * Y2K: Starting the Century Right! * 100 Days to Y2K: A Resource Guide for Small Organizations Category:Software Category:Y2K Category:Definition